home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
IRIX Patches 1995 September
/
SGI IRIX Patches 1995 Sep.iso
/
relnotes
/
patchSG0000533
/
ch2.z
/
ch2
Wrap
Text File
|
1995-09-07
|
13KB
|
330 lines
- 1 -
2. _D_M_A_P_I__I_m_p_l_e_m_e_n_t_a_t_i_o_n__N_o_t_e_s
The following sections describe details of this
implementation that differ in some respect from the
Interface Specification.
Note that this interface is newly created, still under
development, and not yet in use by released products as of
this writing. While due effort and consideration will be
given to maintaining compatibility with this version in
subsequent releases, ccccoooommmmppppaaaattttiiiibbbbiiiilllliiiittttyyyy bbbbeeeettttwwwweeeeeeeennnn tttthhhhiiiissss rrrreeeelllleeeeaaaasssseeee aaaannnndddd
ffffuuuuttttuuuurrrreeee rrrreeeelllleeeeaaaasssseeeessss iiiissss nnnnooootttt gggguuuuaaaarrrraaaannnntttteeeeeeeedddd. This applies both to the
basis for this implementation as described in the Interface
Specification and to the deviations in this particular
implementation as described here.
2.1 _I_m_p_l_e_m_e_n_t_a_t_i_o_n__D_i_f_f_e_r_e_n_c_e_s
This section describes features that have not been
implemented exactly according to their description in the
Interface Specification.
+o The header file is <_s_y_s/_d_m_i._h>, not <_d_m_a_p_i._h>.
+o Since multiple managed regions aren't supported in this
release, _d_m__s_e_t__e_v_e_n_t_l_i_s_t() allows one to set the _r_e_a_d,
_w_r_i_t_e, and _t_r_u_n_c_a_t_e events directly on a file.
+o The _m_a_s_k argument is ignored in the _d_m__g_e_t__b_u_l_k_a_t_t_r(),
_d_m__g_e_t__f_i_l_e_a_t_t_r(), and _d_m__g_e_t__d_i_r_a_t_t_r_s() functions.
All information is returned for every call to any of
these functions.
+o The _d_t__c_h_a_n_g_e field is not present in the _d_m__s_t_a_t
structure.
+o The _b_u_f_l_e_n and _r_e_s_p_b_u_f_p fields are not present in the
_d_m__r_e_s_p_o_n_d__e_v_e_n_t() function.
+o _d_m__w_r_i_t_e__i_n_v_i_s() does buffered, not synchronous writes.
+o Asynchronous events are not sent when an operation
fails. This applies to the _p_o_s_t_c_r_e_a_t_e, _p_o_s_t_r_e_m_o_v_e,
_p_o_s_t_r_e_n_a_m_e, _p_o_s_t_l_i_n_k, _p_o_s_t_s_y_m_l_i_n_k, _a_t_t_r_i_b_u_t_e, and
_d_e_s_t_r_o_y events. These events should be used solely to
determine actual changes in the file system.
+o There are no access rights. Instead, the functions
_d_m__r_e_q_u_e_s_t__r_i_g_h_t(), _d_m__r_e_l_e_a_s_e__r_i_g_h_t(), and
_d_m__q_u_e_r_y__r_i_g_h_t() are replaced by _d_m__a_s_s_o_c__h_a_n_d_l_e(),
_d_m__d_i_s_a_s_s_o_c__h_a_n_d_l_e(), and _d_m__q_u_e_r_y__t_o_k_e_n()
- 2 -
respectively. These replacement functions perform the
same task as the replaced versions with regards to
associating/disassociating a handle with a token. The
sole difference is the absence of the access right
parameter, which controlled locking of the referenced
object. In this implementation no locks are held on
any objects by a process sending an event. Since a
process sending an event may be blocked for various
reasons (including waiting for the receiving DMAPI
application to reply to the event), the possibility of
a lock being held indefinitely is eliminated. This
also eliminates the application's need to determine the
locking state of an object, and allows it to use the
interfaces freely without worrying about blocking due
to a lock it wasn't aware of. The absence of locks
requires a different programming paradigm however.
Applications must enable and receive events on objects
that they wish to have exclusive access to. For
example, to prevent access to a file's data, an
application would enable the _r_e_a_d, _w_r_i_t_e, and _t_r_u_n_c_a_t_e
events on the file, and not respond to any of them
until it was prepared to allow access to the file
again.
2.2 _U_n_i_m_p_l_e_m_e_n_t_e_d__F_e_a_t_u_r_e_s
This section contains a list of the items in the Interface
Specification that are not implemented in this release.
Items listed here are planned for inclusion in future
releases.
+o The functions _d_m__g_e_t__m_o_u_n_t_i_n_f_o(), _d_m__g_e_t_a_l_l__d_i_s_p(), and
_d_m__m_o_v_e__e_v_e_n_t().
+o All of the functions related to extended attributes:
_d_m__c_l_e_a_r__i_n_h_e_r_i_t(), _d_m__g_e_t__d_m_a_t_t_r(),
_d_m__g_e_t_a_l_l__d_m_a_t_t_r(), _d_m__g_e_t_a_l_l__i_n_h_e_r_i_t(),
_d_m__r_e_m_o_v_e__d_m_a_t_t_r(), _d_m__s_e_t__d_m_a_t_t_r(), and
_d_m__s_e_t__i_n_h_e_r_i_t().
2.3 _A_d_d_i_t_i_o_n_s
Additions not described in the Interface Specification are
contained here.
+o The _d_t__i_g_e_n field has been added to the _d_m__s_t_a_t__t
structure. It contains the inode generation number.
+o A function of last resort, _o_p_e_n__b_y__h_a_n_d_l_e() has been
added. Its prototype is:
int open_by_handle (void *hanp, size_t hlen, int rw);
- 3 -
The _r_w argument must be one of _O__R_D_O_N_L_Y or _O__R_D_W_R as in
the _o_f_l_a_g argument to _o_p_e_n(2), The return value is a
valid file descriptor or -1 on error. I/O operations
done using a file descriptor obtained via
_o_p_e_n__b_y__h_a_n_d_l_e() will not update file access or change
times. This function is provided as a workaround for
situations where the handle-based DMAPI interface is
discovered to be insufficient. Any such situations
should be reported so that the necessary functionality
may be included in the interface.
2.4 _K_n_o_w_n__P_r_o_b_l_e_m_s__a_n_d__L_i_m_i_t_a_t_i_o_n_s
This section contains limitations that will be removed in
future releases.
+o The _d_m__g_e_t__d_i_r_a_t_t_r_s() function will not return more
than 30k bytes of information no matter how large the
buffer supplied to it.
+o The _d_m__g_e_t__e_v_e_n_t_s() function returns at most one event
per invocation.
+o Only one managed region may be established per file.
This managed region must encompass the entire file.
+o _d_m__p_u_n_c_h__h_o_l_e() requires the range freed to extend to
the end of the file. _d_m__p_r_o_b_e__h_o_l_e() will properly
return an offset and length corresponding to this
limitation. This restriction is a consequence of being
limited to one managed region.
+o The offset and length given in the _r_e_a_d and _w_r_i_t_e
events are the values supplied to the file system, not
those representing the actual blocks the file system
may read or write in response.
+o Attempting to unmount a file system that has the
_u_n_m_o_u_n_t event enabled will cause the unmount to block
uninterruptibly until the _u_n_m_o_u_n_t event is responded
to. This means that attempting to shutdown the system
when there are mounted file systems with _u_n_m_o_u_n_t
enabled will cause the system to hang. (The shutdown
process kills all user processes, including whatever
process may have handled _u_n_m_o_u_n_t events, leaving no one
to respond to _u_n_m_o_u_n_t events.)
- 4 -
2.5 _I_m_p_l_e_m_e_n_t_a_t_i_o_n_-_d_e_f_i_n_e_d__O_p_t_i_o_n_s
This section describes implementation decisions made for
items listed in the Interface Specification as
"implementation defined".
+o The _d_e_b_u_t event is not supported.
+o Event messages are never dropped. When a message can't
be queued immediately, the generating process is
blocked until it's interrupted or the message is
queued. This applies to both synchronous and
asynchronous event messages.
+o Processes blocked while attempting to queue an event
message on a session are interruptible if they are
blocked waiting for a session that is willing accept
the event message. Processed blocked after queueing an
event message on a session and waiting for a response
are not interruptible.
+o There is a limit of 2048 undelivered messages per
session. Attempting to add more event messages to a
session that has reached the limit will cause the
process generating the event to block until previously
queued messages are delivered.
+o Managed regions and event lists (enabled events) are
persistent.
+o In all synchronous event messages using the
_d_m__n_a_m_e_s_p__e_v_e_n_t structure, the handle given in
_n_e__h_a_n_d_l_e_1 will be associated with the message's token.
Only one handle may be associated with each token.
2.6 _A_d_d_i_t_i_o_n_a_l__I_n_f_o_r_m_a_t_i_o_n
This section contains further explanation of features
implemented according to the Interface Specification, but
whose behavior was not specified fully.
+o All DMAPI functions (except for _d_m__g_e_t__f_i_l_e_a_t_t_r)
require root permissions.
+o The DMAPI is supported only on XFS file systems. The
event generation feature of the DMAPI is enabled at
mount time by using the -_o _d_m_i option to _m_o_u_n_t(2).
This option must be specified for each file system.
File systems with existing DMAPI managed files that are
mounted without the -_o _d_m_i option are completely
accessible by all normal means and no events will be
- 5 -
generated. This is normally extremely undesirable
because programs accessing files may read or write at
locations where data has been migrated. However,
system administrators may find mounting without the -_o
_d_m_i option useful in recovering from a malfunctioning
DMAPI application.
+o The DMAPI functions are in the _l_i_b_d_m._a library. Use
the -_l_d_m compiler/linker option to access the library.
+o For event messages using the _d_m__n_a_m_e_s_p__e_v_e_n_t structure,
the handle associated with the token is always handle 1
(i.e. the handle located by the _n_e__h_a_n_d_l_e_1 field of the
_d_m__n_a_m_e_s_p__e_v_e_n_t structure).
+o On sending the _m_o_u_n_t event: If there are no sessions
at the time a file system is mounted, or if all extant
sessions respond to the mount event with
_D_M__R_E_S_P__D_O_N_T_C_A_R_E, then the mount will proceed. The
only case where a mount will fail due to the result of
delivering or attempting to deliver the _m_o_u_n_t event is
when an application responds to the _m_o_u_n_t event with
_D_M__R_E_S_P__A_B_O_R_T.